\chapter{Testing}
Throughout the development process of the CEAB++ system, frequent testing was
performed to ensure the software being developed was reasonably free of defects
and bugs. Both unit testing and white box testing were performed
to assess the quality of the code being written and to ensure the correct
operation of key features in the system.

To ensure the correct operation of features with complicated business logic,
such as the CEAB validation software module, a series of unit tests were written
to automatically verify individual methods responsible for various parts of the
planner validation work flow. These tests were written to be executed in a very
short amount of time (i.e. less than 10 seconds), allowing software engineers to
quickly verify the correct operation of a certain block of code while working on
a new feature. In addition to providing instantaneous feedback while developing,
unit tests also serve to provide a means of regression testing software,
allowing developers to guarantee that code changes do not impair the correct
operation of other software components in the system. These unit tests also
serve as a form of documentation, as they record the expected behaviour of
certain parts of the software.

While the CEAB++ system's server-side business logic was amenable to unit
testing, it is much more difficult to perform automated unit tests on the
system's HTML and Javascript based user interface. Although automated testing
projects such as Selenium and JSSpec aim to provide a browser-side facility for
automated testing, the team's lack of experience with creating browser-side test
suites prompted a much simpler testing methodology to validate the correct
behaviour of the user interface: white box testing. In white box tests, the
developer interacts with the application in a fashion similar to an end-user,
however the developer uses his/her knowledge of the underlying code to craft use
cases which represent corner cases (or boundary conditions) in the code which
are most likely to result in operating errors or other defects
\cite{ref:testing}. Although this testing methodology is somewhat time
consuming, it provides excellent coverage of user facing features, and is
therefore more likely to catch straight-forward errors such as interface
defects, typos and simple logic bugs.
